Skip to content

[CodeCompletion] Fast completion inside function builder function #32946

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jul 17, 2020

Conversation

rintaro
Copy link
Member

@rintaro rintaro commented Jul 17, 2020

PreCheckFunctionBuilderRequest applies PreCheckExpression to the expressions inside the function body. Previously it used to receive only AnyFunctionRef (FunctionDecl or ClosureExpr) as the parameter. However, when fast-completion kicks-in, it replaces the body of the function, then tries to call PreCheckFunctionBuilderRequest again, with the same function decl as before. It used to return cached "Success" result, but it didn't actually apply PreCheckExpression. So any UnresolvedDeclRefExpr remained unresolved.

In this patch, make PreCheckFunctionBuilderRequest receive "body" of the function as well, so it doesn't return the cached result for the previous body.

rdar://problem/65692922

`PreCheckFunctionBuilderRequest` applies `PreCheckExpression` to the
expressions inside the function body. Previously it used to receive only
`AnyFunctionRef` (`FunctionDecl` or `ClosureExpr`) as the parameter.
However, when fast-completion kicks-in, it replaces the body of the
function, then tries to call `PreCheckFunctionBuilderRequest` again, with
the same function decl as before. It used to return cached "Success"
result, but it didn't actually apply `PreCheckExpression`. So any
`UnresolvedDeclRefExpr` remained unresolved.

In this patch, make `PreCheckFunctionBuilderRequest` receive "body" of the
function as well, so it doesn't return the cached result for the *previous*
body.

rdar://problem/65692922
@rintaro
Copy link
Member Author

rintaro commented Jul 17, 2020

@swift-ci Please smoke test

@rintaro rintaro requested a review from CodaFi July 17, 2020 15:20
@rintaro
Copy link
Member Author

rintaro commented Jul 17, 2020

@CodaFi Is there a better way to differentiate request evaluator keys, for example, manually creating the key from the arguments inside the request?

@CodaFi
Copy link
Contributor

CodaFi commented Jul 17, 2020

When we need to create custom keys, I've taken to using the Descriptor pattern, which will let you define your own custom operator== and hashing primitives. IRGenDescriptor is a good example of going the other way and defining these in terms of less data than you're given. You just want that pattern but with more data.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants